1. Field of the Invention
The present invention relates to the field of data processing and database technologies, and, more specifically, to issuing syncpoints during the execution of a batch application.
2. Description of the Related Art
In very complex data processing systems such as global banking networks run on mainframe systems, a transaction processing system (e.g., Customer Information Control System (CICS) from IBM) manages the interface between application programs and database records. If an application wishes to access a record (i.e., a customer's bank account balance stored on a database), then the transaction processing system will mediate the transaction. The transaction processing system will recall the record from the database, and will place a lock on the record so that no other application can access or update that specific record. Any read or write data requests relating to the record are then processed. Once the application program has finished with the record, a syncpoint is issued to the transaction processing system which results in the lock being removed from the record. No other application can access the record while the lock exists.
In addition to application programs accessing records via a transaction processing system, batch applications are also used to update records. A batch application executes a set of updates which can include very large sets that can consume computing resources of transaction processing systems for an execution period. In the context of a banking system, a batch application may relate to a series of over the counter transactions that need to be applied to the computerized records representing the various bank account details of the customers.
Conventional transaction processing systems impose a lock on all batch records while the batch is processing. Locking the records to prevent other applications from accessing or manipulating the locked records permits the systems to “roll-back” batch manipulations whenever a batch execution fails or whenever an authorized administrator wishes to cancel or reverse an active batch process for any reason. The roll-back removes all changes occurring after the syncpoint so that a data processing system state and record content is the same as it was when the syncpoint was established.
In other words, before a batch application is started, a syncpoint is established. Once a batch application is started, each update is processed in turn. This involves accessing each record to be updated, locking the record and then performing the necessary update. Once all of the records referred to in a batch application have been processed, then a new syncpoint can be issued and all of the locked records can be unlocked and therefore made available to other applications. If a problem occurs during the batch, the pre-batch syncpoint can be used to reverse changes resulting from the aborted batch execution.
Historically, batch processes were executed at times when real-time updates were disallowed. For example, real-time updates occurred during workday hours and batch processes were executed at night when no real-time accesses occurred. Consequently, batch applications did not interfere with other processing since a system could be taken “offline” during a time in which real-time accesses are blocked. All batch applications could be executed at this time. However, with the globalization of markets, integration of databases with remote computing systems, data center consolidation, Web database access capabilities for users (i.e., online banking), remote workplace software tools (e.g., CITRIX, PCANYWHERE, etc.), flexible work hours, and other factors have minimized or eliminated acceptable times for placing a system offline. That is, today's database systems often need to be available for real-time accesses twenty four hours a day. Any downtime can result in significant loss of service to key customers, and/or a loss of revenue to a data processing system owner.
Businesses wish to achieve this capability without expensive changes to their data processing infrastructure. For example, businesses do not wish to replace or re-code batch processing applications which are working properly, yet which have an unfortunate side effect of preventing database access when executing. At the same time, businesses are compelled to provide competitive services which can include 24/7 Internet access to customer records and/or data availability to business partners and their computing systems at all times.
No solutions without significant drawbacks currently exist for handling batch processing while providing increased data availability. For example, data processing centers have implemented partial solutions that are mainly based on tools that minimize the impact of the unavailability of data: either by careful scheduling or by limiting either the scope (i.e., number of data sets included in a batch) of batch related “outages” or their duration. The inadequate solutions that do exist often limit the ability of users to stay current and adopt new technologies since the partial solutions impose limitations that conflict with implementation requirements of emerging technologies, system upgrades, and new data processing or data interfacing techniques. To date, no solution has attempted to eliminate batch related downtime or outages entirely.